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A SURVEY  OF  THE  PROPERTIES  OF 
COMPUTER  COMMUNICATION  PROTOCOLS 
VOLUME  I:  THE  FUNCTION,  PROPERTIES, 
SPECIFICATION,  AND  ANALYSIS  METHODS 
OF  COMPUTER  COMMUNICATION  PROTOCOLS 


1 INTRODUCTION 
Background 


The  ability  to  access  computer  facilities  from  a remote  location 
has  become  increasingly  important.  This  remote  access  capability  makes 
some  previously  expensive  uses  of  computers  economically  effective,  and 
makes  other  uses,  which  until  recently  were  nearly  impossible,  both  fea- 
sible and  practical.  Remote  access  makes  computer  facilities  available 
where  they  were  previously  unavailable,  reduces  the  cost  of  data  pro- 
cessing, and  enables  the  timely  use  of  information  by  organizations  and 
persons  separated  by  large  distances. 

A computer  facility  which  supports  any  type  of  remote  access  capa- 
bility contains  a subsystem  called  the  communications  network.  This 
network  contains  the  communication  links  necessary  to  connect  machines 
and  terminals  at  different  locations.  Each  point  of  the  network  to 
which  either  a terminal  or  computer  may  be  connected  is  called  a node. 
Whether  the  network  has  been  designed  primarily  for  machine  to  machine 
communication,  machine  to  terminal  communication,  or  terminal  to  termi- 
nal communication,  there  must  be  some  agreement  which  defines  how  the 
nodes  may  communicate  over  the  network.  This  agreement  is  called  a com- 
munication protocol.  The  protocol  may  be  simple  or  complex,  depending 
on  the  sophistication  and  function  of  the  devices  which  will  use  it. 


Certain  necessary  functions  and  capabilities  of  communication  net- 
works are  well  defined--for  example,  the  remote  batch  job  entry  facil- 
ity. Though  the  functions  are  defined  in  principle,  their  actual  imple- 
mentations are  not.  It  is  rare  that  two  computers  produced  by  different 
manufacturers  have  any  communication  facility  implemented  in  the  same 
way.  Even  systems  of  a single  manufacturer  may  differ.  It  is  unlikely 
that  these  different  implementations  can  be  standardized  in  the  near 
future.  Therefore,  an  organization  which  must  use  the  services  of  more 
than  one  remote  facility  must  be  prepared  to  support  many  communication 
protocols.  One  major  obstacle  to  this  type  of  support  is  the  lack  of 
any  standardized  method  of  describing  protocols.  Each  designer  develops 
his/her  own  notation,  and  specifications  are  often  ambiguous,  incom- 
plete, and/or  cryptic. 
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Obj  ecti  ve 


The  objective  of  this  report  is  to  survey  the  function,  properties, 
specification,  and  analysis  methods  of  computer  communication  protocols; 
to  discuss  the  criteria  which  have  been  used  for  judging  specifications; 
and  to  recommend  a general  approach  to  the  problem  of  specifying  commu- 
nication protocols. 


Out! i ne  of  Report 

Chapter  2 discusses  aspects  of  data  communications  and  properties 
of  protocols.  Chapter  3 surveys  some  currently  used  methods  of  protocol 
specification,  modeling,  and  verification.  Chapter  4 discusses  the  pro- 
tocol specification  criteria. 
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2 PROTOCOL  FUNCTION  AND  DESIGN 


The  issues  of  data  communication  protocols  can  be  divided  into  two 
levels:  functional  issues  and  design  issues.  Functional  issues  deal 
with  the  execution  time  problems  of  data  communications,  such  as  error 
recovery  and  flow  control.  Design  issues  deal  with  the  reliability  and 
efficiency  of  the  overall  protocol  design.  These  issues  must  be  com- 
pletely resolved  before  the  protocol  is  specified. 


Functional  Issues 

There  are  three  phases  in  a data  communication  procedure:  con- 
nection, message  transfer,  and  termination.  The  phases  may  be  distinct, 
or  they  may  appear  to  merge  together,  depending  on  the  function  and  to- 
pology of  the  communication  network.  There  are  many  functional  issues 
with  which  a protocol  must  deal.  Although  these  issues  are  inter- 
related, they  have  been  divided  for  this  discussion  as  follows: 

1.  Control  of  data  transfers 

2.  Information  coding 

3.  Flow  control 

4.  Message  framing 

5.  Error  recovery 

6.  Protocol  layering. 

Control  of  Data  Transfers 

* 

The  protocol  must  specify  how  each  party  should  control  the  trans- 
fer of  data.  Three  elements  should  be  considered:  message  format,  con- 
trol information,  and  acknowledgements.  The  message  format  specifies 
the  form  of  the  information  contained  in  the  message.  The  format  will 
typically  consist  of  some  leading  control  information  (also  called  a 
header),  the  data,  and  some  trailing  control  information.  Embedded  in 

I the  header  and  trailer  is  control  information,  which  is  typically  used 

to  specify  the  source  and  destination  of  the  message,  and  other  infor- 
mation needed  by  the  receiver  (and/or  the  communication  network)  to  pro- 
cess the  message.  Redundant  information  is  also  generally  provided  for 
use  in  error  recovery  (see  Error  Recovery  section).  The  acknowl- 
edgement, or  hand  shaking,  specifies  the  interaction  of  messages,  how 
the  receipt  of  a message  is  acknowledged,  when  a particular  kind  of  mes- 
sage may  be  sent,  etc. 

Information  Coding 

Information  coding  deals  with  the  meaning  of  the  message,  i.e.,  the 
convention  used  to  interpret  the  bits  transmitted.  The  protocol  must 
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either  explicitly  or  implicitly  specify  the  transformations  needed  to  be 
performed  on  the  message  in  order  to  convert  it  to  and  from  its  trans- 
mitted format  to  the  internal  machine  representations.  There  are  some 
well-defined  code  sets,  such  as  ASCII,1  BCD,  or  EBCDIC.  Other  con- 
ventions exist,  and  others  may  also  be  useful.  The  message  may  be  bit- 
oriented,  so  that  the  bit  combinations  do  not  conform  to  some  character- 
oriented  code  set,  for  example,  transmission  of  binary  data,  or  use  of 
the  SDLC2  protocol.  Conventions  must  be  observed  that  specify  which  bit 
combinations,  if  any,  have  special  meanings  as  control  characters.  In 
addition,  if  a transparency  mode  is  necessary  (a  mode  in  which  all  bit 
combinations  may  be  transmitted  as  valid  data),  conventions  for  the 
entry  and  exit  from  this  mode  must  be  observed. 

Flow  Control 

The  flow  control  properties  of  a communication  protocol  depend  on 
several  factors,  the  most  important  of  which  are  topology  and  re- 
liability of  the  communication  network,  and  the  functional  level  of  the 
protocol.  Protocols  may  exist  at  different  functional  levels.  For  ex- 
ample, in  a message  switching  network  such  as  ARPANET,  3 the  machines  at 
the  nodes  specify  the  destination  of  the  message,  but  the  internal  net- 
work processors  must  route  the  messages  from  node  to  node  until  the  in- 
tended receiver  accepts  the  message.  The  user  does  not  see  the  internal 
network  protocol,  which  specifies  how  messages  are  routed. 

The  topology  of  the  communication  network  partially  dictates  the 
expected  efficiency  of  the  communication  links.  A multipoint  or  multi- 
drop data  link  will  require  more  control  overhead  to  route  messages  than 
a point  to  point  link.  However,  if  the  frequency  of  communication  be- 
tween individual  nodes  is  low,  the  extra  control  overhead  can  increase 
the  utilization  of  the  data  link.  If  there  is  frequent  communication 
between  nodes,  the  extra  overhead  may  cause  contention  problems, 
decreasing  the  utilization  of  the  link. 


American  National  Standard  Procedures  for  the  Use  of  the  Communication 
Control  Characters  of  American  National  Standard  Code  for  Information 
Interchange  in  Specified  Data  Communication  Links , ANSI  X3.28  (ANSI, 
1976  ). 

R.  A.  Donnan  and  J.  R.  Kersey,  "Synchronous  Data  Link  Control:  A Per- 
2 spective,"  IBM  Systems  Journal,  Vol  13,  No.  2 (1974),  pp  140-162. 

J Stephen  D.  Crocker,  John  F.  Heafner,  Robert  Metcalfe,  and  Jonathan 
Postel , "Function-Oriented  Protocols  for  the  ARPA  Computer  Network," 

Proceedings  of  the  Spring  Joint  Computer  Conference , Vol  40,  (American 


Direction  control  is  another  factor.  There  are  three  types  of 
direction  control:  simplex,  half  duplex,  and  full  duplex.  A simplex 
link  allows  transmission  in  one  direction  only.  A half  duplex  link 
allows  transmission  in  both  directions,  but  only  in  one  direction  at  a 
time.  A full  duplex  link  supports  simultaneous  Didirectional  commu- 
nication, and  is  often  modeled  as  two  simplex  links.  A full  duplex  "link 
requires  a protocol  capable  of  handling  simultaneous  two-way  trans- 
mission in  order  to  use  the  link  efficiently. 

The  reliability  of  the  data  links  will  affect  the  flow  of  data  for 
different  protocols.  If  the  network  is  highly  reliable,  and  only  a 
small  number  of  errors  is  expected,  then  the  protocol  will  probably 
specify  error  detection  and  retransmission  schemes.  If  the  reliability 
is  low,  the  protocol  will  probably  specify  a more  complex  error  recovery 
scheme,  which  can  allow  errors  to  be  corrected  in  each  message  without 
retransmission.  If  the  link  is  reliable,  the  number  of  expected  re- 
transmissions will  be  low,  so  that  the  former  method  is  more  efficient. 
If  the  link  is  unreliable,  a large  number  of  retransmissions  could  be 
expected,  and  the  latter  scheme  will  be  more  efficient. 

Flow  control  must  also  deal  with  the  problems  of  source  and  desti- 
nation synchronization.  There  must  be  a mechanism  which  prevents  a 
source  from  producing  messages  faster  than  the  destination  can  process 
them.  Some  protocols  treat  this  as  an  error  condition,  but  this  could 
cause  extra  transmissions  and  overheads.  Another  metnod  is  the  pre- 
allocation  of  buffer  space,  which  increases  control  overhead. 

Message  Framing 

It  must  be  possible  to  determine  the  start  and  end  of  a message. 
Generally,  some  pattern  of  bits,  sometimes  referred  to  as  the  syn- 
chronization pattern,  precedes  the  message.  This  pattern  also  forces 
the  framing  of  the  individual  characters  of  the  message.  If  the  message 
falls  one  bit  out  of  sync,  it  can  become  completely  garbled;  however, 
this  issue  is  generally  only  important  in  low-level  protocols. 

Error  Recovery 

If  all  communication  links  were  error  free,  and  all  nodes  of  a com- 
munication network  were  always  available,  the  design  of  protocols  would 
be  straightforward  and  fairly  simple.  However,  a major  problem  of  pro- 
tocol design  and  specification  is  error  detection  and  recovery.  The 
treatment  of  error  conditions  directly  affects  the  number  of  message  re- 
transmissions, buffer  requirements  at  the  nodes,  line  throughput  and 
utilization,  and  message  delays.  The  different  errors  which  must  be 
detected  and  recovered  include: 
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1.  Transmission  errors 

2.  Sequence  er  ors 

3.  Synchronization  violations 

4.  Long-term  failure. 

Transmission  Errors.  Transmission  errors  change  individual  Bits  in 
a message.  There  are  several  ways  to  detect  and  recover  from  trans- 
mission errors.  Some  systems  require  a destination  to  repeat  the  mes- 
sage to  the  sender.  If  the  message  is  returned  as  it  was  sent,  then  it 
is  assumed  to  be  correct.  However,  most  networks  cannot  afford  this 
amount  of  overhead,  so  error-checki ng  information  is  generally  added  to 
each  message.  Vertical  Redundancy  Checking  (VRC),  also  referred  to  as 
parity,  is  one  such  method.  VRC  adds  one  bit  to  each  character  (byte) 
of  the  message,  and  requires  that  the  total  number  of  bits  set  in  each 
character  be  either  always  odd, or  always  even.  For  example,  using  odd 
parity,  if  the  number  of  bits  set  in  the  character  is  odd,  then  the  VRC 
bit  should  be  set  to  zero;  otherwise,  it  should  be  set  to  one.  This  will 
detect  all  one-bit  errors  in  a character.  This  form  of  error  detection 
can  be  extended  oy  adding  more  VRC  bits  per  character.  For  example, 
there  is  a four-out-of-ei ght  code,  where  only  four  bits  in  an  eight-bit 
character  may  set  to  one.  The  only  errors  not  detected  by  this  method 
are  those  which  cause  an  equal  number  of  zero  and  one  bits  to  change 
value.  There  are  also  codes  which  can  correct  errors,  in  effect  giving 
a multiple-bit  pattern  to  a one-character  mapping. 

The  entire  message  can  be  checked  similarly.  Logitudinal  Redun- 
dancy Checking  (LRC),  also  called  checksum  or  block  checking,  sums  the 
character  codes  for  the  entire  message,  maps  the  sum  into  a single  char- 
acter, and  includes  this  block-checking  character  (BCC)  in  the  message. 
The  destination  node  performs  the  same  operation  on  the  incoming  message 
and  compares  the  checksums.  Cyclic  Redundancy  Checking  (CRC)  is  another 
method  of  message  checking  which  uses  polynomial  division  of  the  message 
to  compute  the  checksum.  These  methods  usually  detect  false  message 
framing,  since  it  is  unlikely  that  a falsely  framed  message  will  have 
correct  checksums.  VRC  and  LRC  are  commonly  used  together  in  data  com- 
munication systems  and  are  effective  when  the  expected  error  rate  is 
fairly  low. 

Sequence  Errors.  Sequence  errors  occur  when  messages  arrive  at  the 
destination  in  a different  order  than  they  were  transmitted  from  the 
source.  An  example  of  this  is  a packet  switching  network,  where  the 
messages  are  divided  into  smaller  packets,  and  each  packet  is  routed 
separately;  however,  networks  where  the  messages  are  not  divided  into 
packets  can  also  exhibit  this  kind  of  error.  For  example,  in  protocols 
which  do  not  require  the  acknowledgement  of  the  previous  message  before 
sending  another  message,  the  second  message  could  arrive  first. 
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Another  type  of  sequence  error  occurs  when  an  expected  message  is 
missing  or  duplicated.  A message  can  be  duplicated  if  the  protocol 
specifies  retransmission  or  no  acknowledgement,  and  the  destination  is 
either  slow  to  respond  or  the  acknowledgement  is  delayed. 

Synchronization  Violations.  Synchronization  violations  occur  when 
the  communicating  nodes  do  not  agree  on  the  state  of  the  communication; 
i.e.,  both  may  be  trying  to  transmit  or  receive.  They  may  be  syn- 
chronized as  source  and  destination,  but  the  message  being  transmitted 
may  be  different  from  the  message  that  the  destination  is  prepared  to 
receive.  This  type  of  error  is  generally  short-term,  and  can  be  caused 
by  a short-term  failure  of  the  communication  link  or  a node. 

Another  type  of  error  occurs  when  a node  is  slow  to  respond  or  when 
a message  is  delayed.  If  one  node  is  waiting  for  a message  and  it  is 
not  delivered  within  some  specified  time,  the  aestination  must  be  able 
to  perform  some  recovery  action.  This  is  commonly  known  as  a time-out. 
When  this  kind  of  error  occurs,  synchronization  must  be  re-established 
whenever  the  transmitting  node  becomes  available.  If  the  node  does  not 
become  available  reasonably  quickly,  the  condition  is  then  classified  as 
a long-term  error. 

Long-Term  Fail  ure.  The  previous  section  dealt  with  short-term  syn- 
chronization problems.  If  communication  between  two  nodes  is  lost  for  a 
long  period  of  time,  tnen  some  specific  recovery  action  may  be  speci- 
fied. If  the  failure  is  in  one  link  of  the  network,  then  messages  may 
be  rerouted  around  that  link.  If  the  node  itself  has  failed,  then  the 
other  communication  nodes  should  be  notified  so  that  they  may  perform 
some  recovery  action.  For  example,  if  the  protocol  is  for  remote  batch 
job  entry,  jobs  may  be  able  to  run  on  another  facility  in  the  network. 

Protocol  Layering 

In  a network  like  ARPANET,4  host  to  host  protocols  are  layered  on 
host  to  IMP  protocols,  which  are  layered  on  IMP  to  IMP  protocols.  Lay- 
ering may  exist  even  in  a simple  point  to  point  protocol.  For  example, 
the  Houston  Instrument  plotters'  are  interfaced  to  the  CDC  UT2UU  remote 
Datch  entry  terminal  by  layering  them  on  top  of  the  existing  line 
printer  protocol.  Any  line  which  begins  with  the  characters  is  di- 
verted to  the  plotter  instead  of  the  printer.  The  lower-level  protocol 
does  not  need  to  be  aware  of  the  higher-level  protocol  above  it. 


Stephen  D.  Crocker,  John  F.  Heafner,  Robert  Metcalfe,  and  Jonathan 
Postel , "Function-Oriented  Protocols  for  the  ARPA  Computer  Net- 
work," Proceedings  of  the  Spring  Point  Computer  Conference 3 Vol  40 

5 (1972),  pp  270-271. 

Batch  Terminal  Controller-Come- lot  BTC-7- 200  Instruction  Manual 

(Houston  Instrument,  Inc.,  revised  May  1972). 
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One  problem  with  layered  protocols  is  error  recovery.  The  fact 
that  a message  is  correct  at  one  level  does  not  mean  that  it  will  be 
correct  at  a higher  level.  Each  level  must  be  prepared  to  handle  error 
conditions,  and  this  may  lead  to  additional  overheads.  Recovery  at  the 
low  levels  can  reduce  the  number  of  errors  detected  at  higher  levels, 
but  will  not  eliminate  them.  Pouzinfi  concludes  that  there  is  no  simple 
criterion  to  determine  at  which  levels  error  recovery  should  appear. 


Design  Issues 

Depending  on  the  individual  communication  network  and  the  intended 
use  of  its  protocols,  the  particular  functional  issues  which  must  be 
considered  and  their  solutions  can  differ  from  protocol  to  protocol. 

The  design  issues  (listed  below),  however,  are  consistent  and  must  be 
considered  for  every  protocol. 

1.  Verification 

2.  Identification  of  protocol  inadequacies 

3.  Detection  of  deadlocks 

4.  Detection  of  critical  races. 

It  must  be  possible  to  verify  that  a protocol  performs  as  required. 
It  is  necessary  to  identify  the  situations  in  which  the  protocol  is  in- 
adequate or  incurs  unacceptable  overheads,  and  be  able  to  redesign  it 
when  necessary.  Possible  deadlock  situations  must  be  detected:  for  ex- 
ample, whether  two  nodes  can  go  into  a receive  state  and  never  return  to 
the  send  state.  Similarly,  critical  races  must  be  detected  (those  con- 
ditions which  may  cause  different  actions  to  take  place,  depending  on 
how  quickly  a message  is  delivered  or  how  a node  responds).  The  error 
recovery  procedure  chosen  must  also  yield  a stable  system;  for  example, 
is  the  protocol  self-synchronizing  (that  is,  does  it  tend  to  synchronize 
itself  even  if  it  was  initially  not  synchronized). 


Louis  Pouzin,  "An  Integrated  Approach  to  NETWORK  Protocols," 

Proceedings  of  the  National  Computer-  Conference  (1975). 
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CURRENT  PROTOCOL  SPECIFICATION  METHODS 


3 


The  design,  verification,  and  implementation  of  communication  pro- 
tocols are  interrelated.  Because  of  this  interrelationship,  the  speci- 
fications and  models  which  have  been  used  in  any  one  of  these  activities 
may  also  be  considered  useful  for  the  others.  The  following  general 
schemes  have  been  used  during  at  least  one  of  the  activities  of  protocol 
desi gn  and  analysis. 

1.  Text 

2.  Communication  control  graphs 

3.  General  machine  descriptions 

4.  Synchronization  models 

5.  Li ngui Stic  model  s 

6.  Specialized  machine  descriptions. 


Text 


Natural  language  text  is  usually  the  first  method  employed  to 
specify  almost  anything.  Its  advantages  are  generality  and  expres- 
sibility.  However,  the  completeness,  conciseness,  and  clarity  of  a tex- 
tual protocol  specification  depend  totally  on  the  author.  Often,  many 
types  of  graphical  aids  accompany  a textual  description  for  the  sake  of 
cl ari ty. 

The  difficulty  with  textual  specifications  stems  from  the  gener- 
ality of  natural  languages.  Two  persons  reading  the  same  text  can  in- 
terpret the  protocol  differently.  The  definition  may  be  ambiguous,  its 
completeness  is  usually  questionable,  and  it  is  often  quite  lengthy. 

One  textual  description  of  the  BSC  protocol,7  which  is  a reasonably  es- 
tablished and  simple  line  control  discipline,  is  36  pages  long,  but  may 
not  be  complete.  It  is  unsuitable  as  an  implementation  guide  because  of 
its  length. 


Communication  Control  Graphs 

Graphical  methods  have  long  been  used  in  conjunction  with  text  to 
clarify  the  exchange  of  messages  and  the  different  possible  inter- 
actions. There  are  several  different  graphical  representations  which 
are  fundamentally  the  same. 


J.  L.  Eisenbies,  "Conventions  for  Digital  Data  Communication  Link 
Design,"  IBM  Systems  Journal,  Vol  6,  No.  4 (1967),  pp  267-392. 
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Time  Line  Diagrams 

The  time  line  diagram  is  laid  out  in  columns,  with  one  column  for 
each  communicating  part  or  station.  The  interactions  of  messages  and 
time  flow  from  the  top  to  the  bottom  of  the  diagram.  The  messages  which 
may  be  sent  or  received  at  each  interaction  are  shown  as  branches  of  the 
diagram  within  the  column  of  the  active  party.  When  a message  is  com- 
plete, the  diagram  crosses  from  the  column  of  the  message  sender  to  the 
column  of  the  message  receiver.  To  illustrate  the  differences  between 
the  graphical  methods,  consider  a two-station  half-duplex  communication 
which  uses  the  control  characters  SOH,  STX,  ETX,  ACK,  and  NAK.  Figure  1 
is  a time  line  diagram  of  a small  fragment  of  the  protocol.8  The  branch 
around  the  SOH  character  indicates  that  it  is  optional. 

ANSI  Representation 

The  ANSI  representation  collapses  the  multiple  column  notation  of 
the  time  line  diagram  into  a single  flow  by  marking  the  line  turnarounds 
(those  positions  in  the  graph  where  the  flow  of  messages  changes 
directions).  Figure  2 is  the  ANSI  representation  of  the  example  proto- 
col fragnent.’  The  graph  is  read  from  left  to  right. 


State  Transition  Graph 

The  state  transition  graph  is  an  extension  of  the  ANSI  repres- 
entation. The  system  states  of  the  communicating  stations  are  added  as 
circles  on  the  graph.  Fiqure  3 is  the  state  transition  graph  of  the  ex- 
ample protocol  fragment.1  The  state  transition  graph  notation  may  be 
converted  into  tables  that  define  a finite  state  machine  which  can  rec- 
ognize the  valid  messages  of  the  protocol. 

Summary  of  Communication  Control  Graphs 

The  graphical  methods  clearly  show  the  flow  of  information  over  the 
communication  link,  and  may  show  the  state  of  the  sender  or  receiver. 
These  methods  can  become  complicated  as  the  complexity  of  the  protocol 
and  the  number  of  stations  increase.  They  are  incomplete  as  a sole 
source  of  protocol  specification,  ignoring  the  transformations  performed 
on  the  messages,  such  as  code  translation  and  parity.  They  may  be  used 
to  show  which  messages  are  possible,  but  not  how,  why,  or  when. 


8 

9 

10 


Byron  W.  Stutzman,  "Data  Communication  Control  Procedures,"  Computer 
Surveys , Vol  4,  No.  4 (December  1972). 

Byron  W.  Stutzman. 

Byron  W.  Stutzman. 
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Figure  3.  State  transition  graph. 


General  Machine  Descriptions 

Since  machines  are  used  in  the  data  communication  process,  one  way 
to  describe  a communication  protocol  is  to  describe  the  actions  of  a ma- 
chine which  can  communicate  using  the  protocol.  In  this  context,  almost 
any  method  that  has  been  used  to  describe  computer  hardware  or  software 
can  be  used  to  describe  a protocol.  Generally,  to  describe  a protocol 
in  this  way,  two  machines  must  be  described:  the  sender  and  the 
receiver.  Often,  both  the  sender  and  receiver  are  the  same  machine. 

Sender-Receiver  Interactions 

One  strai ghtforward  method  of  describing  the  actions  of  two  commu- 
nicating machines  is  to  compare  lists  of  their  actions.  Postel11  uses 
the  following  example. 


SENDER 

RECEIVER 

SO 

Send  message 

RO 

Receive  message 

SI 

Start  timer 

R1 

If  check  sum  = ok 

S2 

If  timer  runout 

R2 

Then  send  ACK 

S3 

Then  retransmit 

R3 

And  go  to  RO 

S4 

And  go  to  SI 

R4 

If  check  sum  = bad 

S5 

If  ACK  received 

R5 

Then  go  to  RO 

S6 

If  check  sum  = bad 

S7 

Then  go  to  S2 

S8 

If  check  sum  = ok 

S9 

Then  go  to  SO 

— 

^ Jonathan  B.  Postel,  A Graph  Model  Analysis  of  Computer  Communication 
Protocols,  Ph.D.  Dissertation,  NTIS  No.  AD  777  506/H  (UCLA,  January 
1974). 


This  example  is  shown  to  be  a simple  positive  acknowledgement  pro 
tocol , but  little  other  information  is  revealed.  The  description  itself 
is  a type  of  structured  text,  and  suffers  from  the  problems  of  te»tual 
descriptions.  It  is  adequate  as  a general  description  meant  to  give  the 
flavor  of  a communication  protocol,  but  not  as  a complete  description 
for  use  as  an  implementation  guide. 

Flow  Charts 

Flow  charts,  used  to  describe  both  computer  hardware  and  software, 
clearly  show  the  flow  of  control  of  an  algorithm.  For  example,  the  pro- 
tocol used  by  the  CDC  200  user  terminal  is  described  in  a detailed  four- 

page  foldout  flow  chart  in  the  r •■■■.'/:  c ifarr\xrc  Reference 

Manual. 12 

The  problems  with  flow  charts  are  similar  to  the  problems  with 
structured  text.  They  may  not  be  sufficiently  detailed  (for  example, 
leaving  critical  implementation  details  unspecified),  or  they  may  become 
too  complex  to  understand. 


Finite  State  Machines 

As  previously  stated,  a state  transition  diagram  can  be  turned  into 
tables  which  define  a finite  state  machine  that  can  recognize  the  proto- 
col. Finite  state  techniques  have  been  used  for  both  protocol  descrip- 
tions and  implementations.13-17  The  basic  procedure  is  to  make  a table 
consisting  of  one  column  for  each  valid  character  in  the  message  and  one 


200  User  Terminal  Hardware  Reference  Manual,  Publication  No.  82128000 

(Control  Data  Corporation,  June  1969). 

Dennis  M.  Birke,  State  Transition  Programming  Tt  * hniques  and  Their 
Use  in  Producing  Teleprocessing  Device  Control  Programs,  M.  S.  Thesis 

14  (University  of  Pittsburgh,  1971). 

Dennis  M.  Birke,  "State-Transition  Programming  Techniques  and  Their 
Use  in  Producing  Teleprocessing  Device  Control  Programs,"  Proceedings 
of  the  2nd  Symposium  on  Problems  in  the  Optimization  of  Data  Commu- 
nications Systems  (Association  for  Computer  Machinery  [ACM],  October 

15  20-22,  1971),  pp  21-31. 

Dines  Bjorner,  "Finite  State  Automation--Defini tion  of  Data  Commu- 
nications Line  Control  Procedures,"  Proceedings  of  the  Fall  Joint 
Computer  Conference  (International  Federation  for  Information  Pro- 
Ik  cessing  [I FIP] , 1970),  pp  477-491. 

0 Gregor  V.  Bochman,  "Communication  Protocols  and  Error  Recovery  Pro- 
cedure," Proceedings  of  the  ACM  SIGCOM!  SIGOPS  Interprocess  Corrm- 
1 i nications  Workshop  (ACM,  March  24-25,  1975),  pp  45-56. 

Byron  W.  Stutzman,  "Data  Communication  Control  Procedures,"  Computer 
Surveys,  Vol  4,  No.  4 (December  1972). 
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row  for  each  state.  The  valid  transitions  from  each  state  to  its  suc- 
cessor state  are  marked  in  the  states  row  in  the  column  of  the  character 
that  will  make  it  change  states.  The  action  that  the  machine  must  per- 
form as  it  makes  the  transition,  such  as  check  message  parity,  is  also 
marked  in  the  table.  All  unmarked  transitions  are  invalid.  Figure  4 is 
an  example  of  the  state  transition  matrix.  Bochman18  extends  the  no- 
tation to  specifically  show  whether  the  action  performed  is  a local 
action,  a send  action,  or  a receive  action. 


CURRENT 

STATE 


EVENT 


soh 

six 

a 

etx 

ock 

nok 

Invalid  or 
no  reply 

1 

A, 2 

8.4 

2 

C.3 

3 

E,4 

D.3 

4 

F.5 

5 

G,5 

H,  6 

6 

1,1 

A-J  ROUTINES  TO  BE 
PERFORMED  UPON 
TRANSITION  TO  THE 
NEXT  STATE 

a - TEXT  CHARACTERS 


Figure  4.  State  transition  matrix. 


The  problem  with  the  finite  state  description  is  that  the  actions 
the  protocol  machine  is  to  perform  are  not  formally  specified.  Also, 
there  are  no  guarantees  that  finite  state  machines  are  sufficient  to  de- 
scribe all  protocols. 

Cornpu  ter  Programs 

The  most  complete  description  of  a protocol  machine  which  exists  as 
a computer  program  is  the  computer  program  itself.  Most  protocol  de- 
scriptions are  transmitted  as  programs.  Unfortunately,  however,  most 
protocol  machines  are  programmed  in  assembly  language,  which  requires 


Gregor  V.  Bochman,  pp  45-56. 
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the  user  to  have  specific  knowledge  of  the  implementation  hardware  in 
order  to  transfer  it  to  another  machine.  Also,  since  machine  architec- 
tures vary  widely,  the  description  may  need  drastic  revision  before  the 
protocol  will  function  on  another  machine.  Protocol  machines  generally 
require  the  use  of  interrupt  processing,  and  so  tar  there  is  no  commonly 
used  high-level  language  which  handles  asynchronous  processing  clearly 
and  efficiently.  However,  this  is  currently  an  active  research  area. 
Brinch  Hansen1'  nas  developed  a language  based  on  Pascal20  called  Con- 
current Pascal.  This  language  is  designed  to  handle  systems  of  commu- 
nicating asynchronous  processes  and  has  a computer  operating  system 
written  into  it.  Hansen  and  Lindahl?1  have  specified  a similar  language 
called  R^al-Time  Pascal.  Wirth  has  designed  a language  called 
Modula,''  also  based  on  Pascal,  which  is  oriented  toward  the  DEC  PDP-11 
computer.  The  analysis  of  protocol  software  is  subject  to  all  of  the 
problems  of  general  software  analysis  and  verification. 

Swmarit  of  General  Machine  Deth-yrn.pt tone 

Protocols  that  are  based  on  general  machine  descriptions  are  prom- 
ising. They  can  be  complete;  they  are  executable,  thereby  affording 
some  verification  of  their  operation;  and  they  seem  to  be  the  shortest 
path  to  implementation  of  a protocol.  The  problem  appears  to  be  that 
general  methods  do  not  yield  a clear  enough  description,  independent  of 
some  hardware,  to  be  easily  usable.  Two  special  forms  of  machine  re- 
presentations will  be  discussed  in  the  Specialized  Machine  Descriptions 
Section. 


Recently,  there  has  been  much  interest  in  verifying  and  analyzing 
the  actions  of  protocols.  Synchronization  properties  have  received  much 
attention.  Within  the  context  of  this  work,  several  different  for- 
malisms have  evolved  which  have  been  used  for  different  analyses.  While 
none  of  these  models  seems  to  be  general  enough  to  be  used  alone  as  a 
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Per  Brinch  Hansen,  Conaurvent  Pascal  Introduction  and  Concurred  t 

2Q  Pas'al  Report  (California  Institute  of  Technology,  July  1975). 
u Kathleen  Jensen  and  Niklaus  Wirth,  Pas. -a:  User  Manual  and  Report 
(Springer-Verlag,  1975). 

Gilbert  J.  Hansen  and  Charles  F.  Lindahl,  Preliminary  Specification 
of  Real  Time  Pascal,  Technical  Report  NAVTRAEQUIPCEN  7 6 - C - 00 17-1, 
NTIS  No.  AD  A03  1451  (Computer  Laboratory,  Naval  Training  Equipment 
22  Center,  July  1976). 

c Niklaus  Wirth,  "Modula:  A Language  for  Modular  Multiprogramming," 
"The  Use  of  Modula,"  and  "Desiqn  and  Implementation  Modula,"  I'aftwar .. 

Practice  and  Exp'erience,  Vol  7,  No.  1 (January,  February  1977). 
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protocol  description,  some  have  properties  which  may  prove  to  be  useful 
as  part  of  a total  description.  The  following  are  some  of  the  more 
prominent  models  mentioned  in  recent  literature. 

Petri  Nets 


Petri  nets'1  ?s  ar * designed  to  model  the  synchronization  problems 
of  a system  composed  of  concurrent  asynchronous  processes.  This  is  a 
directed  graph  model  which  has  two  types  of  nodes:  places  and  transi- 
tions. A place  which  is  connected  to  a transition  via  an  arc  is  called 
an  input  place  of  the  transition  node  if  it  precedes  the  transition,  and 
is  called  an  output  place  if  it  follows  the  transition.  Places  may  be 
marked  by  zero  or  more  tokens.  On  the  Petri  net  diagram,  a place  ap- 
pears as  a circle,  a token  as  a heavy  dot,  and  a transition  as  a line 
perpendicul ar  to  one  of  its  arcs.  The  state  of  the  system  is  repres- 
ented by  the  pattern  of  tokens  on  the  places,  which  is  called  the  mark- 
ing. The  system  changes  states  by  moving  tokens.  The  mechanism  which 
moves  the  tokens  is  the  firing  of  a transition.  A transition  fires 
where  each  of  its  input  places  has  at  least  one  token.  The  action  of 
the  transition  is  to  remove  one  token  from  each  of  its  input  places,  and 
to  add  one  token  to  each  of  its  output  places.  Figure  5 is  an  example 
of  a Petri  net. 

Petri  nets  can  clearly  show  the  overall  state  of  a system  of  commu- 
nicating processes.  The  possible  sequence  of  states  is  identifiable. 
Certain  properties  of  the  Petri  net  have  a direct  bearing  on  the  system 
stability.  The  practical  problem  with  Petri  nets  is  that  they  get  so 
complex  that  it  becomes  nearly  impossible  to  analyze  a real  system. 

The  UCLA  Graph  Model 

The  UCLA  graph  model26  has  been  used  by  Postel  as  an  alternative  to 
Petri  nets  for  analyzing  protocols.  The  model  consists  of  arcs  and 
nodes,  where  the  arcs  correspond  to  the  flow  of  control  and  the  nodes 


Robert  C.  Chen,  "Representation  of  Process  Synchronization," 

Proceedings  of  the  ACM  SIGCOMM/SIGOPS  Interprocess  Communications 
2Q  Workshop  (ACM,  March  24-25,  1975),  pp  37-42. 

Kurt  Lautenbach  and  Hans  A.  Schmid,  "Use  of  Petri  Nets  for  Proving 
Correctness  of  Concurrent  Process  Systems,"  Proceedings  of  IFIP  74 

25  (IFIP,  1974),  pp  187-191. 

Pamela  B.  Thomas,  The  Petri  Net  as  a Modeling  Tool,  NTIS  No.  K/CSD/ INF- 
76/8  , CONF  760430-1,  presented  at  the  14th  Annual  Southeast  Regional 

26  ACM  Conference,  Birmingham,  Alabama  (April  22-24,  1976). 

Jonathan  B.  Postel,  A Graph  Model  Analysis  of  Computer  Communication 
Protocols,  Ph.O.  Dissertation,  NTIS  No.  AD777506/H,  (UCLA,  January 
1974). 
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represent  computations.  The  major  advance  of  the  UCLA  graph  model  over 
Petri  nets  is  the  addition  of  input  and  output  logic  for  a node.  Petri 
nets  use  only  an  "and"  logic,  requiring  that  all  input  places  have  at 
least  one  token  and  all  output  places  receive  one  token.  The  UCLA  graph 
model  allows  either  "and"  logic  or  "exclusive  or"  (EOR)  logic  for  both 
node  input  and  output.  When  EOR  logic  is  used  on  input,  the  node  may 
choose  which  input  to  remove  the  token  from,  if  more  than  one  is  marked. 
Similarly,  on  output,  the  node  chooses  the  position  of  the  token. 

Figure  6^ ' is  an  example  of  a UCLA  graph  model;  represents  "and" 
logic,  and  “+"  represents  "exclusive  or"  logic.  Although  the  graphs  may 
become  complicated,  Postel  has  found  that  some  graphs  may  be  reduced 
into  graph  modules,  which  can  simplify  the  analysis  of  the  graphs. 


Other  Synchronization  Models 


The  subjects  of  interprocess  synchronization  and  communication  are 
active  areas  of  research.  Other  tools  from  these  areas  which  may  apply 
to  the  protocol  area  include  the  use  of  semaphores,28  critical 
regions, 28  and  monitors30  to  insure  mutual  exclusion.  These  techniques 
are  oriented  toward  processes  which  share  some  common  memory.  A differ- 
ent approach  is  to  use  an  algebra-like  notation  to  specify  the  allowable 
synchronization  as  opposed  to  the  exclusion.  This  "path  expression  no- 
tation31'33 specifies  the  allowable  orderings  of  activities.  There  are 
various  notations  used.  For  example,  is  used  as  a sequencing  oper- 
ator, "+"  is  used  as  an  "exclusive  or"  operator,  and  is  used  to  mean 
zero  or  more  times.  The  expression  "path  (a  ; ( b + c )*)  end"  means 
that  an  allowable  execution  can  consist  of  an  occurrence  of  "a"  followed 


Jonathan  B.  Postel , A Graph  Model  Analysis  of  Computer  Communication 

Protocols , Ph.D.  Dissertation,  NTIS  No.  AD  777  506 /H  (UCLA,  January 
28  1974). 

F.  W.  Dijkstra,  "Hierarchical  Ordering  of  Sequential  Processes," 
Operating  Systems  Techniques , C.  A.  R.  Hoare  and  P.  H.  Perrot,  eds. 

2g  (Academic  Press,  1972). 

Per  Brinch  Hansen,  "Concurrent  Programming  Concepts,"  Computing  Sur- 

30  veys,  Vol  5,  No.  4 (ACM,  December  1973),  pp  223-245. 

C.  A.  R.  Hoare,  "Monitors:  An  Operating  System  Structuring  Concept," 

31  CACM,  Vol  17,  No.  10  (October  1974),  pp  549-557. 
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Synchronization  by  Path  Expressions,"  Proceedings  of  an  International 
Symposium  Held  at  Racquencourt  on  Operating  Systems  (Springer  Verlag 
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A.  N.  Habermann,  Path  Expressions  , Technical  Report  (Computer  Science 
Department,  Carnegie-Mellon  University,  June  1975). 

P.  E.  Laver  and  R.  H.  Campbell,  "Formal  Semantics  of  a Class  of  High 
Level  Primatives  for  Coordinating  Concurrent  Processes,"  Ada  Infor- 
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by  zero  or  more  occurrences  of  either  "b"  or  "c."  Work  is  continuing  in 
this  area,  and  its  ultimate  application  to  protocols  is  not  yet  deter- 
mined . 


Li ngui Stic  Model s 

The  data  communications  process  has  been  compared  to  communications 
by  formal  language, 34  with  the  communications  message  considered  to  be  a 
sentence.  Thus,  it  is  possible  to  use  much  of  the  work  done  in  the  area 
of  parsing  languages  to  describe  protocols.  The  language,  consisting  of 
all  the  allowable  messages,  is  specified  by  a formal  grammar,  usually  in 
a BNF  notation.  This  can  directly  describe  an  automaton  which  can 
receive  (parse)  the  messages.  It  is  neater  and  more  powerful  than  the 
finite  stage  graph  method  for  complex  messages,  but  suffers  from  many  of 
the  same  problems.  Although  the  allowable  messages  are  well  described, 
several  items  are  not  specified  formally:  how  and  when  the  messages  are 
generated,  how  they  are  used,  and  those  functions  termed  "semantics"  in 
the  compiler  areas.  Figure  735  is  an  example  of  a protocol  specified 
using  BNF  notation. 
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Figure  7.  A lingoistic  description  using  BNF. 

( xx  is  any  valid  text  character; 
1=1  indicates  a line  turnaround.) 


Hans-Jurger  Hoffman,  On  Linguistic  Aspects  of  Communication  Line  Con- 
trol Procedures , IBM  Report  No.  RZ345  (IBM  Research  Laboratory,  Feb- 
35  ruary  2,  1970) . 

3 Hans-Jurger  Hoffman. 
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Special ized  Machine  Descriptions 

Recent  work  in  defining  abstract  machines  for  describing  commu- 
nication protocols  could  allow  programming  technology  to  be  applied  to 
protocols,  without  dependence  on  a particular  implementation.  The  fol- 
lowing approaches  have  appeared  recently. 

IntCVLh  ‘U  t , ' CS 

Danthine  and  Bremer36’37  have  modeled  a protocol  as  a colloquy  be- 
tween two  special  machines  called  interlocutors.  Each  interlocutor  has 
three  inputs  and  outputs  and  a set  of  internal  states.  The  inputs  are 
for  text  from  the  other  interlocutor  (the  communications  links),  text 
from  the  user  for  transmission  to  the  other  user,  and  commands  from  the 
user.  The  outputs  are  text  to  the  other  interlocutor,  text  to  the  user, 
and  commands  for  the  user  (see  Figure  8). 16  The  internal  structure  of 
the  interlocutor  consists  of  a processing  unit,  an  input  unit,  an  output 
unit,  and  several  buffers.  The  processing  unit  is  divided  into  two 
parts:  one  deals  with  fixed  operations  (Danthine  lists  eight),  and  one 
deals  with  the  variable  part  of  message  processing,  called  context  pro- 
cessing. The  operation  of  the  fixed  portion  is  governed  by  a set  of  ma- 
trices defined  for  the  protocol  and  application.  Figure  93?  shows  the 
internal  structure  of  an  interlocutor.  The  problem  with  the  inter- 
locutor approach  appears  to  be  that  the  context  processing  part  has  not 
yet  been  sufficiently  structured.  The  parts  of  a protocol  that  require 
the  most  analysis  would  likely  fall  into  this  category,  thus  defeating 
many  of  the  advantages  of  the  structure. 
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Figure  8.  Communication  structure  of  two  interlocutors  of  a colloquy. 
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Andre  A.  S.  Danthine  and  Joseph  Bremer,  "An  Axiomatic  Description  of 
the  Transport  Protocol  of  Cyclades,"  Professional  Confers,,  n-  on  'cm- 
puter  Networks  and  Teleprocessing  (March  31  - April  2,  1976). 

Andre  A.  S.  Danthine  and  Joseph  Bremer,  "Communication  Protocols  in  a 
Network  Context,"  Proceedings  of  the  ACM  SIGCOMM/SIGOPS  Interprocess 
30  Cormunications  Workshop  (ACM,  March  24-25,  1975),  pp  87-92. 

J Andre  A.  S.  Danthine  and  Joseph  Bremer,  "An  Axiomatic  Description  of 
Cyclades,"  Professional  Conference  on  Computer  Networks  and  Tele- 
processing  (March  31  - April  2,  1976). 
y Danthine  and  Bremer. 
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Figure  9.  Internal  structure  of  an  interlocutor. 


Protocol  Machines 

Gouda  and  Manning40-42  have  defined  a "Protocol  Machine"  as  an 
entity  capable  of  communicating  with  other  compatible  protocol  machines 
via  sent  and  received  messages.  Each  protocol  machine  consists  of  two 
structures:  a data  structure  and  a control  structure.  The  control 
structure  is  a directed  graph,  called  a sequence  graph,  which  has  four 
possible  types  of  nodes:  (1)  the  send  node,  (2)  the  receive  node, 

(3)  the  update  node,  and  (4)  the  decision  node.  A subclass  of  protocol 
machines  (sr  machines)  which  have  only  send  and  receive  nodes  has  also 
been  identified.  The  data  structure  which  the  protocol  machine  may  ma- 
nipulate consists  of  variables  that  map  to  and  from  fields  in  the  mes- 
sage^  that  may  be  sent  or  received.  Figure  1043  shows  a sample  data 
structure  and  sequence  graph  for  a protocol  machine.  Gouda  and  Manning 
have  shown  that  send  and  receive  nodes  have  direct  representations  as 
Petri  nets.  The  approach  appears  to  have  some  promise,  although  the 
model  does  not  presently  appear  to  be  general  enough  to  represent  arbi- 
trary protocols.  In  particular,  it  appears  that  asynchronous  processing 
is  excluded. 


Mohamed  G.  Gouda  and  Eric  G.  Manning,  "On  the  Modelling,  Analysis, 
and  Design  of  Protocols--A  Special  Class  of  Software  Structures," 
Proceedings  of  the  2nd  International  Conference  of  Software 
Engineering,  IEEE  No.  76CH1125-4C  (Institute  of  Electrical  and  Elec- 
tronic  Engineers  [IEEE],  1976)  pp  256-262. 

Mohamed  G.  Gouda  and  Eric  G.  Manning,  "Protocol  Machines:  A Concise 
Formal  Model  and  Its  Automatic  Implementation,"  Proceedings  of  the 
3rd  International  Conference  on  Computer  Communication  (International 
42  Council  for  Computer  Communication,  August  3-6,  1976),  pp  346-350. 
Mohamed  G.  Gouda  and  Eric  G.  Manning,  "Toward  Modular  Hierarchical 
Structure  for  Protocols  in  Computer  Networks,"  Proceedings  of  Compcon 
76  (IEEE,  September  1976). 

"On  the  Modelling,  Design,  and  Analysis  of  Protocols." 
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Figure  10a.  Sequence  graph. 


Figure  10b.  The  data  structure  of  a protocol  machine. 

Program  Process  Modeling  Language 

Riddle1*4  uses  a programming  language  form  of  notation  (the  Program 
Process  Modeling  Language  [PP ML])  to  model  the  message  transfer  activ- 
ities of  a system  of  asynchronous  processes.  The  language  does  not 
provide  details  about  the  internal  operation  of  each  process,  but  the 
sending  and  receiving  of  messages  and  the  internal  flow  of  control  are 
modeled.  Riddle  also  develops  an  algebra-like  notation  to  describe  mes- 
sage flow  within  the  system,  called  Message  Transfer  Expressions  (MTE). 
The  basic  modeling  scheme  chosen  does  have  some  limitations:  in  partic- 
ular, the  direct  modeling  of  synchronous  communication  is  not  possible. 
However,  the  overall  approach  appears  to  be  very  promising. 


William  Ewing  Riddle,  The  Modeling  and  Analysis  of  Supervisory  Sys- 
tems, Ph.D.  Dissertation  (Stanford  University,  1972). 
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Summary 

Each  of  the  preceding  models  has  merit  for  particular  applications 
and  analyses,  but  each  is  primarily  applicable  to  communications  over 
error-free  channels.  However,  some  work  has  been  done  (for  example, 
by  Sunshine1*'1  which  considers  error-prone  communication  links. 
Schneider1*6  has  proposed  a uniform  all-inclusive  modeling  technique  to 
model  error,  efficiency,  overhead,  and  other  properties  of  protocols. 
There  does  not  appear  to  be  any  consensus  at  this  time  concerning  which 
approach  is  most  promising. 


| 
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n PROTOCOL  SPECIFICATION  CRITERIA 


This  report  has  surveyed  the  Functional  requirements  of  commu- 
nication protocols  and  the  ways  in  which  protocols  have  been  specified, 
analyzed,  and  implemented.  Throughout  the  survey,  the  inter- 
relationships of  the  different  phases  of  the  protocol  life  cycle  re- 
quirements, design,  analysis,  implementation,  and  use  have  become  appar- 
ent. Furthermore,  any  protocol  specification  or  description  should  be 
useful  during  all  phases.  Bochman'* 7 has  defined  three  general  proper- 
ties that  a protocol  specification  should  have. 

1.  The  protocol  specification  should  be  in  a comprehensive  form. 

2.  The  protocol  specification  should  allow  the  proving  of  certain 
protocol  properties,  particularly  that  the  error  recovery  is  effective, 
and  that  all  possible  situations  have  been  considered. 

3.  The  protocol  specification  should  lead  easily  and  naturally 
toward  its  implementation. 

A protocol  specification  must  not  only  be  complete,  but  it  should 
be  provably  complete.  It  should  be  useful  at  each  phase  of  the  protocol 
life  cycle  and  should  not  require  reinterpretation  to  be  useful  at  an- 
other phase.  It  must  be  comprehensive  and  unambiguous.  It  should  be 
possible  to  partition  a protocol  specification  into  different  levels  of 
abstraction.  Protocol  layering  should  also  be  apparent  in  the  specifi- 
cation; when  a specification  depends  on  a lower-level  protocol,  this 
should  be  explicitly  noted.  The  protocol  specification  should  be  inde- 
pendent of  any  particular  hardware  or  any  particular  implementation.  It 
should  clearly  indicate  how  the  functional  issues  of  the  protocol  are 
re  sol ved. 


47 

Gregor  V.  Bochman,  "Cormiunicati on  Protocols  and  Error  Recovery  Pro- 
cedures," Proceedings  of  the  ACM  SIGCOMM/SIGOPS  Interprocess  Communica- 
tions Workshop  (ACM,  March  24-25,  1975),  pp  45-50. 
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5 SUMMARY  AND  CONCLUSIONS 


This  report  has  surveyed  the  current  status  of  communication  proto- 
cols. The  issues  of  protocol  design  are  considered  in  two  categories: 
functional  issues  and  design  issues.  The  functional  issues  vary  from 
protocol  to  protocol,  depending  on  its  intended  function  and  environ- 
ment. The  design  issues  deal  with  the  reliability  and  efficiency  of  the 
protocol,  and  should  be  considered  for  any  protocol. 

The  methods  employed  to  describe  and  analyze  protocols  range  from 
informal  textual  descriptions  to  very  formal  specific  machine  repres- 
entations. Bochman's  goal s--comprehensive  form,  proving  of  properties, 
and  natural  implementation--are  used  as  a general  basis  for  evaluating 
protocol  specification  methods.  No  currently  used  representation  was 
found  to  be  sufficient  as  the  sole  method  of  specifying  protocols. 

No  general  approach  to  the  specification  of  communication  protocols 
can  be  ruled  out  at  this  time;  however,  it  appears  that  methods  of  the 
general  machine  description  class  are  more  likely  to  lead  toward  a 
useful  specification  methodology,  since  they  directly  describe  the  ac- 
tions of  the  communicating  parties,  which  is  what  must  be  implemented. 
The  finite  state  subclass  is  useful  when  the  state  space  of  the  protocol 
is  reasonably  small,  since  it  is  concise,  directly  impl ementabl e,  and 
analyzable.  However,  when  the  state  space  is  large,  a more  general  ap- 
proach must  be  taken. 

The  trends  observed  in  some  of  the  newer  computer  languages  can 
lead  to  a language  which  is  machine  independent,  efficiently  imple- 
mentable,  and  suitable  as  a vehicle  for  protocol  specification  and  im- 
plementation. Current  work  in  languages  should  be  augmented  to  include 
the  formal  description  of  messages  and  the  primitive  operations  which 
manipulate  the  messages.  Techniques  to  analyze  the  behavior  of  systems 
of  communicating  parties  specified  in  this  way  must  also  be  developed  in 
order  to  detect  abnormal  conditions  such  as  critical  races  and  dead- 
locks. The  combination  of  these  approaches  into  a unified  methodology 
can  lead  to  the  better  understanding  and  implementation  of  communication 
protocol s. 
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0017-1,  NTIS  No.  ADA031451  (Computer  Laboratory,  Naval  Training 
Equipment  Center,  July  1976). 

This  report  describes  a programming  language  based  on  PASCAL  for 
use  in  real  time  control  applications. 
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of  sentences  in  a language.  Linguistic  treatment  defines  the  rules 
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This  paper  describes  the  initial  work  on  a processor  for  supporting 
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This  paper  defines  a resource-sharing  computer  network,  and  looks 
at  user  services  that  can  be  provided.  Some  current  design  prob- 
lems are  outl ined. 
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66.  fundamentals  of  Computer  Network  Communications , No.  SP0076  (Sperry 
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68.  Wirth,  Niklaus,  "Modular  A Language  for  Modular  Multiprogramming," 
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